Could this pr have anything to do with #1467 and #228? By reading the lines you edited it seems like those issues can be closed (after this pr is merged).

EDIT: it seems like the video title is missing from the metadata, is that true? If so, could you please add it?

@Stypox the title and mediaId are set in the constructor a few lines above.
Sometimes its just a device issue.

I was first excited when I saw this PR as I was the one that introduced the "additionalMetadata" bundle but getDuration didn't work for me.
But I guess it is also a device issue for me as my car (Kia Stinger 2018) does still not show the correct duration even with these changes added.

But I am happy that it works for you @m0n1ker
I am just unable to report an improvement for me personally but at least there is no regression :)

edit: maybe we should still put METADATA_KEY_TITLE in case this field is read by some awkward bluetooth devices?

@Stypox This might help #1467, but I kind of doubt it. I'm running android 9 on a Galaxy S9 and it does not show the media controls as described in the issue. I only see the notification widget, which is working for me, so I'm not able to test this specific issue on my device.

As far as #228, again I think it will make the exposed metadata more reliable but I'm not sure this really resolves the feature request as stated. I looked at adding the album art to the metadata, but it was causing some other issues that I haven't been able to solve. If I can get that working I can submit another PR for it.

@Redirion I'm surprised this didn't change anything in your car. It's new enough it should be able to correctly handle metadata, but bluetooth receivers are weird sometimes. I've verified the metadata being sent with the bluetooth-player utility that is a part of Linux's "bluez" bluetooth stack. It prints out metadata and playback status messages as they are sent, and I'm seeing the proper data and playback states being sent now.

I agree that adding METADATA_KEY_TITLE to the additional metadata would be a good idea. It doesn't hurt anything, and if it makes it more widely compatible with bluetooth receivers that's an easy win. I'll push another commit after this comment.

As an additional note, I think the issue with #228 has more to do with the fact this app is implementing MediaDescriptionCompat but not MediaMetadataCompat. From what I can tell, the description object is meant for lightweight display-only purposes such as showing items in the play queue. The full MediaMetadataCompat object is the preferred one for showing details about an individual item in the queue, such as the currently playing track, and adding support for this may actually help both the bluetooth car audio issues and the issues associated with #228. This is something I'd like to explore more when I have some time.

@m0n1ker Thanks! The code looks good.

As an additional note, I think the issue with #228 has more to do with the fact this app is implementing MediaDescriptionCompat but not MediaMetadataCompat. From what I can tell, the description object is meant for lightweight display-only purposes such as showing items in the play queue. The full MediaMetadataCompat object is the preferred one for showing details about an individual item in the queue, such as the currently playing track, and adding support for this may actually help both the bluetooth car audio issues and the issues associated with #228. This is something I'd like to explore more when I have some time.

Yes, that could solve the problems. I am glad that you want to take a look at it.

Is someone capable of testing this with a different car or device? I don't own a car which supports Bluetooth. If not, this shouldn't be a problem, because the changes don't look like they can break something.